In Gutenberg, we want to register all blocks on the server with PHP and don’t repeat it on the client. For the mobile app, there is a need to have those definitions to be loaded in JS as of today and maybe through network-based API later. Standalone Gutenberg which Riad works on would benefit from purely client-side block definitions loading.

So, the contents of block.json would be bundled with the JavaScript. But in the context of WordPress, the server would register the block using the same block.json, largely to the effect that the registration can become "known" PHP-side. And we still bootstrap this into the client, which takes precedent over the bundled metadata (though likely it is the same).

Am I understanding correctly?

So, the contents of block.json would be bundled with the JavaScript. But in the context of WordPress, the server would register the block using the same block.json, largely to the effect that the registration can become "known" PHP-side. And we still bootstrap this into the client, which takes precedent over the bundled metadata (though likely it is the same).

In overall, this is exactly what I'm envisioning with one small remark. Once this data is available on the server and is discoverable through API, we should always serve it from the server. Therefore the need to have it bundled into the client no longer makes sense. To avoid code duplication and make the bundle size smaller, we can remove this metadata from the client in a WordPress context.

Therefore the need to have it bundled into the client no longer makes sense. To avoid code duplication and make the bundle size smaller, we can remove this metadata from the client in a WordPress context.

Gotcha. That would be good; the one thing which stood out to me is that we'd have the data be duplicated. I suppose the reason for doing it this way is to allow for a more iterative conversion to a system where blocks become known by fetching data from an API, rather than explicitly registering as we do today in edit-post? It's still unclear (and perhaps yet-unsolved, I'm unsure) how the JavaScript implementation of the block would become known to the editor in this system. Or am I mistaken in thinking on this process of how blocks become known to the editor? It seems like it could be the necessary path for dynamically loading new blocks via e.g. some of the inserter concepts for installing new blocks.

I suppose the reason for doing it this way is to allow for a more iterative conversion to a system where blocks become known by fetching data from an API, rather than explicitly registering as we do today in edit-post?

Yes, that is exactly what would happen at some point. Server and client would have the same list of all blocks expressed with metadata format. That would make it possible to automatically register blocks exposed by the server rather than doing it explicitly as of today. However, it's still unclear to me how we would connect metadata with block settings which can be expressed only with JavaScript. On the other hand, things like edit implementation aren't necessary until the block is inserted into the editor so it doesn't have to be registered immediately. This makes it more complicated but at the same time creates very interesting opportunities to load have logic only when it's actually needed.

It's still unclear (and perhaps yet-unsolved, I'm unsure) how the JavaScript implementation of the block would become known to the editor in this system. Or am I mistaken in thinking on this process of how blocks become known to the editor? It seems like it could be the necessary path for dynamically loading new blocks via e.g. some of the inserter concepts for installing new blocks.

This is one of the possible flows we could implement:

• from the Inserter you call API which returns the list of block metadatas from WordPress.org Block Directory
• based on that you somehow display them in the inserter (name, title, description, category, keywords is all you need probably)
• when you select the block, behind the scenes it gets installed on the server, the same way as if you would go to the Plugins page
• placeholder block is inserted into the editor
• once it’s installed, JS and CSS gets loaded into the editor, placeholder blocks gets transformed into this newly installed block

@youknowriad @aduth - do you feel like we can land this PR as is and continue with the following roadmap:

• use inline JSON babel plugin as the first step with one block (this PR)
• update more client-side blocks to work with this plugin
• replace inline JSON Babel plugin with our own version which supports i18n
• add more fields to block.json
• update Babel plugin to bundle block.json metadata only when not using server-side registration
• figure out the way to register all static blocks on the server with some custom Gutenberg specific loader based on the block.json

Some tasks can be done in parallel which might make the development process more convenient.

Can we merge it as is and work on follow-up PRs?